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REMARKS 

I. Introduction 

Claims 1-45 were rejected. Claims 1,15, 28, and 32 were amended. Claims 2 and 29 
were cancelled. The amendment is supported by the originally filed disclosure. No new 
matter has been added. Reconsideration of the application is respectfully requested in light of 
the amendment and based on the following remarks. 

II. Rejection of Claims 1-13.15-35. 37. 39, 41, and 43 under 35 U.S.C. S 103(a) 
over Koch and Cover 

Claims 1-13, 15-35, 37, 39, 41, and 43 stand rejected over "Michael Koch (Leverage 
legacy systems with a blend of XML, XSL, and Java®, October 6, 2000, JavaWorld.com)'* 
C'Koch") in view of "Robin Cover (Apache Xalan XSLT Compiler (XSLTC) Integrated into 
the Java® Web Services Developer Pack (WSDP), August 26, 2002, OASIS)" ("Cover"). 
Claims 2 and 29 were cancelled, mooting the rejection, although the features of these claims 
were incorporated into their parent claims 1 and 28. Claims 1 5 and 32 were also amended to 
improve clarity. . Applicants respectfully submits that claims 1,3-13, 15-28,30-35, 37, 39, 
41, and 43 are allowable over the cited references and respectfully request withdrawal of the 
rejection. 

To reject a claim as obvious under 35 U.S.C. § 103, the prior art must disclose or 
suggest each claim feature. (See Northern Telecom, Inc. v. Datapoint Corp. , 908 F.2d 931, 
934 (Fed. Cir. 1990), cert, denied . Ill S. Ct. 296 (1990); In re Bond , 910 F.2d 831, 834 (Fed. 
Cir. 1990))- The factual inquiry whether to combine references must be thorough and 
searching and must be based on objective evidence of record. In re Lee, 277 F.3d 1338 (Fed. 
Cir. 2002). 

Independent claim 1 was amended to incorporate features of claim 2. As amended, 
claim 1 recites: 

1 . A method of processing messages comprising: 

receiving a markup language document describing a message, the 

markup language document being compliant with message rules associated 

with an OLTP language; 

automatically generating source code in a program language from the 

markup language document; 

compiling the source code; 
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using the compiled source code to transform a payload message 
between the program language and the online transaction processing (OLTP) 
language. 

The Office Action cites the Koch reference for all the features of claim 1 except for 
"generating source code, compiling the source code, and the source code being generated 
automatically," for which the Office Action relies on the Cover reference. 

The Koch reference generally describes transforming an XML formatted message 
received from an application for conversion to a format usable with a legacy application. 
XML describes the format of Koch's original message (and the converted end format of the 
response message sent in reply). See, e.g., Koch Figure L Applicant notes that the XML as 
used by Koch is neither a program language nor an OLTP language . Koch uses a Java engine 
doing XSL processing to perform data conversion, requiring a programmer to write code to 
perform this transformation. See Koch at 2 ("Referencing the structure above, you can write 
the code to hook up your values. . ..") 

In contrast, Applicant's claim 1 recites that a markup document L "compliant with the 
message rules associated with an OLTP" language is received. This feature is entirely absent 
from Koch because Koch's initial message is already an XML message. The claimed markup 
docxxment L, rather than describing the input data structure (as in Koch) describes how to 
make the message compliant with the OLTP system, which provides a more powerful 
approach to data conversion between many types of systems. In particular, there is no 
requirement in the claimed method that there be an existing XML definition of the messages 
coming from or going to the client system, as is required in Koch. 

Once the markup document is received. Applicant's claimed method then 
automatically generates source code in a program language (not the OLTP language) from 
the markup language document that can be used to transform payload messages between the 
program language and the OLTP language. Koch also lacks this feature. As noted above, 
Koch requires a program be written to perform data transformation. These absence of these 
features is not cured by the Office Action's proposed addition of Cover. 

Moreover, since XML is a markup language used to describe the structure of files , 
and as such, is not a program language . Thus, Koch does not identically disclose the recited 
feature of the claimed method "transform a payload message between the program language 
and an online transaction processing (OLTP) language". Since Cover does not cure this 
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deficiency in Koch and is not asserted to cure this deficiency in Koch, claim 1 is allowable 
for at least this additional reason. 

Additionally, Koch does not disclose "automatically generating source code in a 
program language from the markup language document." Cover is asserted to allegedly cure 
this deficiency. There are several problems with the Cover reference. Cover generally 
discloses an XSLTC, extensible stylesheet language transformation complier. "XSLTC 
works by transparently compiling XSL stylesheets into Java byte code (translets), which can 
then be used repeatedly to perform XSLT transformations on one or many XML files." See 
Cover sec. 2. Claim 1 recites "compiling the source code". In contrast. Cover discloses 
"compiling XSL stylesheets". Thus, for Cover to disclose each and every claim feature, 
"XSL stylesheets" must be "source code." However, claim 1 recites what is generated is 
source code in a program language. XSL stylesheets are not a program language as used 
in claim 1 . XSL is a "stylesheet language," which is not a program language. Moreover, 
though Java bytecode, which is a programming language, may be the output in some parts of 
Cover's system, Java bytecode is not source code. For at least this additional reason claim 1 
should be allowable 

Even if combining Koch and Cover would be obvious, which Applicants do not agree 
it would be, the combined prior art must disclose or suggest each claim feature. Both Koch 
and Cover fail to disclose at least the features "transform a payload message between the 
program language and the online transaction processing (OLTP) language" and 
"automatically generating source code in a program language". For at least these additional 
reasons Claim 1 should be allowable. 

Claims 3 to 14, 36, and 37 ultimately depend on claim 1 and should be allowable for 
at least the same reasons. 

Claim 15 recites features similar to claim 1, including "receiving a markup language 
document . . . compliant with message rules associated with an [OLTP] system." Thus, claim 
15 should be allowable for similar reasons to claim 1 . Claims 16 to 22, 38, and 39 ultimately 
depend from claim 15 and should be allowable for at least the same reason. 

Independent claim 23 includes features similar to features found in claims 1 and 15. 

Claim 23 recites: 

A method of processing messages comprising: 

receiving one or more extensible markup language (XML) documents, 
the XML documents being compliant with message rules associated with an 
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online transaction processing (OLTP) language, the OLTP language being a 
gaming system language and the message rules defining markup tags for 
describing components of the message; 

compiling the XML documents into source code in an object-oriented 
program lansua^e based on stylesheet data, the stylesheet data representing a 
program template for a payload message in the program language, the source 
code enabling transformation of the message between the prosram lansuase 
and the OLTP language; 

compiling the source code; 

using the compiled source code to transform a message between the 
program language and the OLTP language, the source code beins: generated 
automatically: and 

repeating the receiving and compiling of XML documents and the 
compiling of source code for a plurality of message types. 

None of the cited references discloses or even suggests at least the above-highlighted claim 
features. As argued with regard to claim 1, Koch generally discloses communications 
between "XML" and "a legacy system." See. Koch Figure 1 and Sec. "The versatile XML" 
par. 1 . XML is neither a program language nor an OLTP language . XML is a markup 
language, and as such, is not a program language . Thus, Koch does not identically disclose 
"transform a payload message between the program language and an online transaction 
processing (OLTP) language". Furthermore, Cover discloses "XSLTC works by 
transparently compiling XSL stylesheets into Java byte code (translets), which can then be 
used repeatedly to perform XSLT transformations on one or many XML files." Since Java 
byte code is not "source code" Cover fails to teach the feature of "compiling the XML 
documents into source code . . ." Also as mentioned with regard to prior claims. Cover fails 
to disclose "the source code being generated automatically ." For at least these reasons claim 
23 should be allowable. 

Claims 24 to 27, 40, and 41 depend on claim 23, and should be allowable for at least 
the same reasons. 

Claim 28 recites similar features as claims 1,15 and 23, which are not disclosed by 
Koch nor Cover. Specifically, claim 28 recites a "development module to generate source 
code in a program language," and a "message parser to transform a payload message between 
the program language and an online transaction processing (OLTP) language, the 
development module to generate the source code automatically.'''* As argued above, neither 
Koch nor Cover discloses the above identified features. Claim 28 should be allowable for at 
least those reasons. 
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Claims 29 to 3 1 and 43 depend on claim 28 and should be allowable for at least the 
same reasons. 

Claim 32 recites similar features as claim 15. Similarly, neither Koch nor Cover 
discloses "compile the markup language document into source code.'''' Claim 32 is allowable 
for similar reasons as claim 15. Specifically, because neither Koch nor Cover discloses the 
quoted claim feature, an obviousness rejection is improper and claim 32 should be allowable. 

Claims 33 to 35 and 45 depend on claim 32 and should be allowable for at least the 
same reasons. 

II. Rejection of Claims 14. 36. 38. 40. 42, 44 under 35 U.S.C. S 103(al over Koch and 
Cover in view of Boushy 

Claims 14, 36,38, 40, 42, and 44 stand rejected over Koch and Cover in further view 
of Bouchy (U.S. Patent 5,003,013). All of these claims depend from claims addressed 
previously, and therefore should be allowable for at least the reasons their respective parent 
claims are allowable. 

Moreover, with respect to claims 36, 38, 40, 42, and 44, these claims all recite the 
payload message is part of a wagering transaction or similar features. The Office Action 
admits that Koch and Cover do not disclose this feature. Applicant respectfully submits that 
Boushy also does not disclose a "payload message is part of at least one of the wagering- 
related transactions and comprises at least one of: a request to place an online wagen or a 
response to the request to place the online wager .". Boushy generally discloses tracking the 
worth of players in a casino. Nowhere does Boushy teach or suggest online wagers. For at 
least this additional reason, claims 36, 38, 40, 42, and 44 should be allowed. 

Moreover, with respect to all of claims 14, 36,38, 38, 40, 42, and 44, the Office 

Action proffers that an ordinary artisan would have been motivated to 

fiirther enhance the Koch-Cover's system by taking, advancing, and/or 
incorporating Boushy' s system which offers significant advantages for 
differentiating customers according to their worth to the casino; customer 
information is accumulated at each affiliated casino through one or more 
LAN-based management systems, updated to a central patron database that is 
coupled to each casino LAN through a WAN, and made available to each 
affiliated property as needed as once suggested by Boushy. 

Office Action at 37. 
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Applicant respectfully submits that all the Office Action has done is mash references 
together in a pure hindsight reconstruction. Neither Koch nor Cover address gaming systems. 
And Bouchy does not address data transformations for legacy systems or anything similar. 
Thus, the motivation to combined proffered in the Office Action is insufficient to make out a 
prima facie case of obviousness, because it fails to explain at all why an ordinary artisan 
would be motivated to combine the references. Rejections on obviousness groimds cannot be 
sustained by mere conclusory statements; instead, there must be some articulated reasons 
with some rational underpinning to support the legal conclusion of obviousness. In re Kahn, 
AA\ F.3d 977, 988 (Fed. Cir. 2006). 

III. Conclusion 

Applicants respectfully submit that all pending claims of the present application are 
allowable. It is therefore respectfully requested that the rejections (and any objections) be 
withdrawn. Prompt reconsideration and allowance of the present application are therefore 
respectfully requested. The Commissioner is authorized to charge any fee arising from the 
submission of this paper to Deposit Account 1 1-0600 of Kenyon & Kenyon LLP. 



Respectfully submitted. 




Andrew L. Reibman 
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